Appl. No. 10/733,345 

Amdt. dated February 22, 2008 

Reply to Office Action of October 18, 2007 

Remarks 

The Office Action has objected to the specification under 37 CFR § 1 .75(i). in 
response, claims 1 and 1 6 have been amended to separate each element 
or step of the claim by a line indentation. Claim 1 has been further 
amended to correct a typographical error. 

The Office Action has rejected claims 1-18 under 35 U.S.C. 102(e) as being 
anticipated by US Patent Application Publication Number 2003/0050794 to 
Keck, et al. (hereinafter ''Keck"); Applicant traverses the rejections for the 
following reasons. 

Keck teaches a method and system for provision of hospital care to ensure 
efficient utilization of hospital resources and to optimize reimbursement of 
hospital expenses. The system taught in Keck comprises a computing 
device, as depicted in Figure 1, which contains a memory and processor to 
store and run the application for implementing the method, as well as a 
display device with an optional touchscreen etc. (see also paragraphs 27 
and 30). In general, the system taught in Keck is meant to be operated by 
hospitai staff to capture all treatments performed on a patient over a given 
time period which makes billing easier and further allows periodic reports to 
be generated (see paragraph 24). 

The application taught in Keck is embodied in a flowsheet, for example in 
LOTUS® (see paragraphs 24 and 25), in which hospital staff record patient 
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data by clicking on relevant cells and entering desired information 
(paragraph 25), As is depicted in Figures 4a and 4b, and described in 
paragraphs 30 and 31, the flowsheet is very clearly based on a grid system, 
similar to a spreadsheet, in which all the relevant cells are presented to the 
hospital staff at once. As such Keck does not teach or suggest at least one 
main question and a plurality of dependent questions linked to a response of 
said main question and each other, as the hospital staff entering data into 
the cells simply need to capture the procedures that are being performed 
on a patient. Indeed, to trained hospital staff, a series of questions would be 
viewed as an irritant, and further counter to the purpose of Keck, which is to 
enable the medical professionals to quickly and efficiently enter and 
capture data. Indeed, paragraph 30 specifically makes reference to the 
layout and categories of data defined in the spreadsheet as being 
particularly useful in a hospital Emergency Department, based on the 
inventor's years as an administrator of such a department. Conspicuous by 
its absence is any mention of a question/response model in paragraph 30, or 
any other paragraph of Keck. 

The system taught in Keck is further not meant to be used by patients, and 
indeed is meant to address the problem of how to ensure that billable 
procedures performed on unconscious patients are captured for billing (e.g. 
paragraph 3). Hence Keck specifically teaches away from patient 
interaction with the application. Further, Keck only contemplates entering of 
data into the flowsheet after intake/triage has been performed (e.g. see 
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Figures 2, 3 and paragraphs 28 and 19, in which the computing devices of 
Figure 1 are clearly shown as being away from a triage station (i.e. an 
intake/admitting room) and hence are further not located proximal to a 
waiting area of a hospital emergency room, nor directed to intake of a 
patient in said hospital emergency room. 



In contrast, the present application is directed towards providing: 



"A computing device for location proximal to a waiting area of a 
hospital emergency room and for intake of a patient in said hospital 
emergency room comprising a touch-screen operable to receive input 
by allowing said patient to depress active portions along the surface of 
said touch-screen, said touch screen further operable to display 
information to said patient; said computing device further comprising a 
set of headphones connected to said computing device for presenting 
audio output to said patient; and wherein said computing device is 
configured to receive an identification of said patient and a preferred 
language of said patient, and further operable to present on said touch 
screen at least one main question and a plurality of dependent 
questions linked to a response of said main question and each other, 
said questions presented in said preferred language of said patient, 
said questions pertaining to an intake procedure of said patient to said 
hospital, said device further operable to receive responses to each of 
said questions by touch screen input from said patient, said device 
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further operable to generate an intake report based on said responses 
in a preferred language of a hospital staff member responsible for 
further processing of said intake of said patient. " 



Keck cannot possibly teach the subject matter as claimed in the present 
application. First of all Keck is directed towards tracking information after a 
patient has undergone intake/triage and treatment has commenced. As 
such, Keck is directed for use by hospital staff and cannot possibly teach il a 
touch-screen operable to receive input by allowing said patient to depress 
active portions along the surface of said touch-screen" because a patient 
would not have access to the system of Keck. 



Second, Keck cannot possibly teach "to present on said touch screen at 
least one main question and a plurality of dependent questions linked to a 
response of said main question and each other, said questions presented in 
said preferred language of said patient, said questions pertaining to an 
intake procedure of said patient to said hospital", as Keck is in no way 
meant to be used by patients, nor is Keck directed towards an intake 
process, for the reasons discussed above. Further, Keck does not teach or 
suggest presenting questions to patients for similar reasons, or questions of 
any kind, also discussed above, and directed solely towards capturing 
information in a flowsheet, the cells of which are presented all at once to 
hospital stuff such that the cells may be filled in by hospital staff. 
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Thirdly, and for similar reasons, Keck cannot possibly teach "to generate an 
intake report based on said responses in a preferred language of a hospital 
staff member responsible for further processing of said intake of said patient" 
as Keck is not directed towards intake, but rather tracking information after 
intake has occurred. 

Finally, the Office Action asserts on page 3 that "user defined inputs" of Keck 
is interpreted to encompass "preferred language of said patient". Applicant 
respectfully disagrees. Ail instances of the term "user defined inputs" in Keck, 
including references to the prior art, refer solely to inputs relating to medical 
procedures, patient routing, billing (e.g. paragraph 5), patient history, test 
results, medical findings (paragraph 6), billing codes (paragraph 26), patient 
and hospital resource utilization data (paragraph 27), date, 
hospital/department information, patient information, time by process, 
patient fate and testing performed (paragraphs 1 1 and 30 in combJh.crfio.nJ. 
Indeed, from paragraph 27 of Keck, it is clear that user-defined fields in the 
meaning of Keck refer simply to user-defined fields in the flowsheet: in other 
words specific information pertaining to the stay of the patient in the hospital 
that is stored in a particular cell in the flowsheet, in no way can user-defined 
inputs encompass preferred language of said patient within the meaning of 
the subject matter claimed in the present application, for example "said 
questions presented in said preferred ianauaae of said patient". 
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Hence, it is believed that the application is in condition for allowance, 
and allowance is requested. To the extent that any issues remain to be 
resolved, however, Applicant requests that the Examiner contact the 
undersigned to resolve these issues. 

The Commissioner is authorized to charge the extension of time fees to 
the Credit Card on file with the Office. The Commissioner is also authorized 
to charge any shortage in fees due in connection with the filing of this 
paper, including extension of time fees, to Deposit Account No. 50-3750. 



Date: February 2^, 2008 

PERRY + CURRIER 

1 300 Yonge Street, Suite 500 

Toronto, Ontario 

CANADA, M4T 1X3 

Tel. No. (416) 920-8170 

Fax No. (416) 920-1350 

Customer No.: 54640 



Respectfully submitted, 




Agent of Applicant 
T. Andrew Currier 
Registration Number 45,400 
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